In the prior art, different multicast routing protocols have been defined to distribute subscription interest in a communications network. Some examples include the IP multicast routing protocols such as DVMRP (IETF rfc1075), PIM (IETF rfc4601), MOSPF (IETF rfc1584), and Solace's content-routing protocol XSMP (U.S. Pat. No. 7,801,857).
Existing IP multicast routing protocols require dynamic creation and management of (Source-Network, Published-Multicast-Group) state (i.e. (S,G) state) in each router, on a per-published-mcast-group basis. This results in scaling issues when there are a large numbers of potential groups that a publisher can send on, especially if the multicast groups are not IP addresses, but are a hierarchical topics, since the topic subscriptions may be wild-carded, and could match an infinite number of published topics. Furthermore, if messages are being routed based on message content, as discussed in U.S. Pat. No. 7,801,857, then it is impossible to maintain (S,G) state in the router, as there are no explicit published-multicast-groups to maintain state on.
SMRP does not maintain (S,G) state in the router, and thus is highly scalable in applications where the number of routers in the network is small compared to the number of potential published multicast groups, which can be very large or infinite.
In content routing networks, SMRP is an alternative routing protocol to the XSMP protocol described in U.S. Pat. No. 7,801,857. SMRP scales to a much higher number of subscriptions in the network, and solves a fundamental scaling issue with XSMP that resulted in the protocol overhead for a published message consuming more network bandwidth than the message itself when the message was being delivered to a large number of routers. Unlike XSMP, SMRP does not require the insertion of a “destination list” into each message, or the modification of that “destination list” in each router. The “destination list” was fundamental to XSMP, and was very costly in terms of end-to-end latency, per-router processing overhead per message, and network bandwidth consumption when the message needed to be delivered to a large number of routers in the network.
Of the existing prior art, the Subscription Management and Routing Protocol (SMRP) described in this invention has the strongest similarities with MOSPF, but differs significantly from MOSPF in the following areas:                MOSPF combines physical topology and mcast subscription propagation in a single routing protocol. SMRP is only responsible for subscription propagation, and the invention incorporates modifications to an existing underlying link-state protocol (such as Solace's XLSP Protocol (U.S. Pat. No. 7,801,857), or OSPF (IETF rfc2328), or IS-IS (ISO/IEC 10589:2002)), to construct a per-source-router Pruned SPF Tree and Pruned FIB which contains the reachability information for each router in the network. The Pruned FIB is used in conjunction with the subscription information provided by SMRP to provide loop-free forwarding of the multicast data messages.        MOSPF builds, in each router, a forwarding tree per (source network, mcast destination). This results in the construction and maintenance of a large number of forwarding trees. SMRP builds, in each router, a SMRP routing table, which contains a lookup tree of (mcast-subscription→{subscribing router list}), where a given mcast-subscription in the tree can be either a fully-qualified subscription or a wildcarded subscription. When a data message arrives, the message's mcast destination is looked up in the SMRP routing table, and the list of all matching {subscribing routers} is retrieved from the routing table. That {subscribing router list} is then passed through an underlying Pruned FIB to determine which next-hop(s) the message must be delivered to. This two-stage lookup can easily be implemented in hardware for very high performance, eliminates the need to maintain (S,G) state, and results in a much smaller number of forwarding trees that need to be maintained per router compared to MOSPF, or other IP multicast routing protocols        MOSPF must dynamically build a new forwarding tree whenever it encounters a data message published to an (S,G) pair that it has not seen before. SMRP does not ever need to build new forwarding tables based on the contents of a data message, and the underlying SPF routing mechanism only needs to recompute the Pruned SPF trees and Pruned FIBs when a new router is discovered in the network, or the physical topology of the network changes.        MOSPF must flush all the forwarding trees for all (S,G) pairs if the physical topology of the network changes. SMRP is not impacted by topology changes, the underlying SPF routing mechanism simply recomputes the Pruned SPF trees and Pruned FIBs when the physical topology of the network changes.        MOSPF sends a separate Link-State-Advertisement (LSA) message per multicast subscription. This can result in large numbers of LSAs needing to be advertised when connectivity to a router is lost and then restored. SMRP groups subscription information into subscription blocks which can be summarized and compared following a connectivity failure, so that only the changed blocks need to be readvertised when connectivity is restored. SMRP also provides the ability to advertise delta updates to the subscription blocks, to minimize the network overhead of advertising individual subscription updates.        SMRP uses the periodic flooding of DbSummary messages to refresh routing state in the network, thus avoiding the need to periodically flood/refresh the full multicast subscriptions as is common in the art today.        